Creating Content Plan Templates (RIM)

Content plan templates define the structure and hierarchy when users create new content plans.

Note: This feature is only available on RIM Submissions Vaults.

About Content Plan Templates

You create content plan templates using the Content Plan Template and Content Plan Item Template objects. The Content Plan Template object allows self-referencing relationships, so you will use one record as the highest level in the template and additional records to create sections and subsections.

Content Plan Template and Content Plan Item Template records form the basic structure of the content plan that Vault creates:

Content Plan Template records correspond to Content Plan records comprising the content plan hierarchy’s sections and subsections.
Content Plan Item Template records correspond to Content Plan Item records, or the leaf nodes where documents are expected.

About Dynamic Content Plan Creation

In addition to the configured template record hierarchy, Vault uses template record metadata to dynamically create content plan records. For example, a token in a Content Plan Template record’s Name field generates sections (Content Plan records) or expected documents (Content Plan Item records) that repeat based on the Submission’s relationships.

Similarly, some Content Plan Template and Content Plan Item Template field values specify the scenarios in which Vault should create Content Plan records, based on the Submission’s metadata and relationships.

Some use cases for this include:

Populating “United States” as the Lead Market Country (country__rim) in a Content Plan Template record to specify that Vault should create a Content Plan record (section) only when the United States Country record is related to the Submission (on the related Application record). When creating the content plan, Vault populates values for any fields that have the same Name on both the Content Plan Template and the Content Plan objects.
Populating the XML ICH DTD / XSD Version or XML Regional DTD / XSD Version fields to create Content Plans for multiple XML versions which are concurrently accepted by a Health Authority.

About XML Version-Specific Content Plan Templates

Vault can use the XML ICH DTD / XSD Version and XML Regional DTD / XSD Version fields to dynamically create content plans based on:

The eCTD or XML versions used for the Submission to account for regulatory updates over time.
Multiple eCTD or XML versions which are accepted for a short period of time.

For example, the current US regional XML schema version is 3.3. If the FDA updates the schema to v3.4 while still supporting v3.3, Vault can accommodate Content Plans based on two sets of template records: One where template records specify the XML Regional DTD / XSD Version as 3.3, and another where template records specify version 3.4.

The XML ICH DTD / XSD Version field is also useful for setting an index Content Plan Item with ICH 3.2 so that when a non-eCTD Submission Content Plan is created, Vault does not create an index Content Plan Item.

To create content plans based on XML version, select the appropriate XML ICH DTD / XSD Version or XML Regional DTD / XSD Version value on the following supported Content Plan Template and Content Plan Item Template types:

Regional (Module 1)
Summary (Module 2)
Quality (Module 3)
Nonclinical (Module 4)
Clinical (Module 5)
Other

Creating Content Plan Templates

To create a content plan template:

Navigate to the Content Plan Templates record list through Business Admin or a custom tab.
Click Create and set up the highest level content plan in this template. The Name should be something understandable for users who are creating Submission or Report Level Content Plan records and filling in the Content Template field.
Click Save + Create to save and start adding child-level Content Plan Template records.
Enter details for the first section within the template. You may want a numeric value in Name to help organize the sections, for example, 1 Administrative Information for the first section and 1.1 Correspondence for its first subsection. If a section should use a token, enter the token in the Name field. In the Parent field, select the Content Plan Template record you created earlier to set a hierarchical relationship between the current record and the first record.
Optional: Populate fields like XML ICH DTD / XSD Version or XML Regional DTD / XSD Version to create content plans based on the XML version. Similarly, you can populate fields like Region (region__rim) and Lead Market Country (country__rim) to specify that the Content Plan Template record of the template only applies to specific submissions, based on the submission’s metadata and relationships. For example, specifying Lead Market Country: United States on a section means that Vault only creates that section if the United States Country record is related to the Submission (on the related Application record). When creating the content plan, Vault populates values for any fields that have the same Name on both the Content Plan Template and the Content Plan objects.
Optional: If configured by an Admin, populate the Exclude from Auto-matching field on the Content Plan Template record. When selected, Vault will not enable auto-matching to this Content Plan section when the content plan enters the lifecycle state that turns on auto-matching. See About the Exclude from Auto-Matching Field.
Click Save + Create to add the next section.
Continue to repeat this process until the structure of the content plan is complete. If you need to step back and see the hierarchy as you go, open the Hierarchy Viewer. Content Plan Templates do not use the grid-based Content Plan Hierarchy Viewer.
In the Hierarchy Viewer, open the Create menu and select Content Plan Item Template. Individual Content Plan Items represent a document that you intend to collect for the submission. You can include tokens in the Name field. Click Save + Create to save and add the next Content Plan Item.
Optional: Populate fields like Region (region__v) and Lead Market Country (lead_market_country__v) to specify that the Content Plan Item Template record only applies to submissions with a matching region and lead market. For example, specifying Lead Market Country: China on an item means that Vault only creates that item if the China Country record is on the related Application record.
Repeat this process until the template includes Content Plan Items that represent each document.

Alternatively, you can create Content Plan Template records in bulk using Vault Loader.

Using Tokens

You can add tokens to the Name field within your Content Plan Template hierarchies to create sections (child-level Content Plan records) or expected documents (Content Plan Item records) that repeat based on the submission’s relationships. Vault creates repeating sections in alphabetical order. You can also add Application and Submission tokens to the top-level Content Plan Template to help with auto-naming. These don’t repeat.

For example, using a Content Plan Template record named (1) “3.2.S Drug Substance - ${submission_active_substance__regulatory}” to create a content plan generates sibling content plans (2) for each Submission Active Substance record (3):

This functionality is available for the Submission object and specific objects with a join relationship to the Submission object. Join object records connect a specific Submission record to other records in your Vault to define the scope of the submission. For example, Submission Country is the join object between Submission and Country.

See also Limitations and Supported Tokens for token-specific behaviors.

Finding and Setting Tokens

Before beginning template creation, you’ll need to collect the Object Name and other field name values for any objects related to the Submission object. These values can become tokens within your template.

To find these values, navigate to Admin > Configuration > Objects and locate and open the related object. The Details tab displays the Object Name, and Field Names are found in the corresponding column within the Fields tab. For example, the name for Submission Clinical Studies is submission_clinical_studies__rim, and the name of one of its object fields, Clinical Study, is clinical_study__rim.

Setting Tokens

Tokens for content plans follow the same general format as system-managed object record names: When resolving a token referencing an object field, Vault displays the value from the field defined after the object in which it appears. Otherwise, Vault resolves the object Name.

For example:

To populate with the Submission Clinical Study field XML Clinical Study ID, use the token ${submission_clinical_study__rim.xml_clinical_study_id__v}
To populate with the Submission Language, use the token ${submission_language__rim}

When creating Content Plan Template and Content Plan Item Template records, you can add tokens to the below fields.

Name
Title (xml_title__v)
Filename (for Content Plan Item Templates only)
Folder Path (for Content Plan Templates only)
XML Element Name (for Content Plan Templates only)

Token values within the Title, Filename, Folder Path, and XML Element Name fields resolve in the content plan, but will not create repeating sections. Additionally, the Folder Path and Filename fields combine to set the Published Output Location on a created Content Plan Item record.

Supported Tokens

Vault supports tokens for Submissions, Content Plans, Report Level Content Plans, and matched documents.

Submission

Vault supports tokens for object reference and text fields on the Submission object.

Long Text, Rich Text, and Formula fields, and fields referencing the User object are not supported.

Submission Content Plan

Vault supports tokens for object reference and text fields on the below submission join objects. Long Text, Rich Text, and Formula fields, and fields referencing the User object are not supported.

${submission_pharmaceutical_product__rim}
${submission_active_substance__rim}
${submission_inactive_ingredient__rim}
${submission_indication__rim}
${submission_clinical_study__rim}
${submission_nonclinical_study__rim}
${submission_country__rim}
${submission_language__rim}
${submission_pharmaceutical_form__v}
${submission__v.xml_submission_id__v}
${submission_pharmaceutical_form__v}

Additional token resolution behavior in Submission Content Plans includes:

When a token is used in a record where the field is blank, the token text is not resolved. Unresolved tokens are resolved when you add a value to the field and run the Update Content Plan action.
When a tokenized field value is updated, the Update Content Plan action updates the token text and refreshes the value from the template.
When Vault detects differences in non-token text (leading up to a token) between corresponding Content Plan Item and Content Plan Item Template records, the text and the token are not refreshed.

Report Level Content Plan

Vault supports the below tokens for Report Level Content Plans. The report level plan join record Name is used to resolve the token value.

${report_level_plan_clinical_study__v}
${report_level_plan_nonclinical_study__v}
${report_level_plan_product_family__v}

Matched Document

Vault supports tokens for object reference and text fields on matched documents. For example, you can set the ${matched_document.clinical_site__v} token in the filename to organize Case Report Forms in the appropriate site folders for the Published Output Location.

Long Text, Rich Text, Autonumber, and Formula fields are not supported. When using tokens in object fields, if the referenced object field is multi-select and has multiple associated records, only the first value is resolved in the token.

Examples of commonly-used tokens include ${matched_document.name__v} and ${matched_document.title__v}.

When used, Vault resolves the token with the value from the field defined after matched_document. For example, if using the ${matched_document.ectd_title__v} token, the ectd_title__v field value is resolved in the token.

Vault only resolves matched document tokens when the document count equals the expected document count. If the expected document count is one (1), the token resolves when there is a single document matched to the Content Plan Item.

About the Output Name Field

You can leverage the Output Name text field to define a unique value to tokenize in the content plan that is not represented by an existing field, such as a shortened name.

For example, a clinical study section references the Submission Indication, defined as “Multiple Sclerosis” through the ${submission_indication__rim} token. However, this indication must be expressed in a different format within the Published Output Location. The alternate indication name (“multiplesclerosis”) can be defined in the Output Name field.

About Clinical and Nonclinical Study Tokens

Vault creates repeating sections for clinical and nonclinical studies only when the Study Type and Study Subtype defined in the Submission Clinical Study or Submission Nonclinical Study record record match the Study Type and Study Subtype defined on the template record containing the clinical study or nonclinical study token.

For example, a content plan template defines the ${submission_clinical_study__rim} token in Section 5.3.1.1 with a Clinical Study Type and Clinical Study Subtype of Biopharmaceutical and Bioavailability (BA):

A Marketing Submission (0000) has two related clinical studies, ABC-123 and CL 123, where ABC-123’s Clinical Study Type and Subtype are defined and match the template, and CL 123’s Clinical Study Type and Subtype are not yet populated.

In the resulting content plan, Section 5.3.1.1 includes a subsection with a Biopharmaceutical Type and Bioavailability (BA) Subtype, which match the respective values defined for ABC-123. A section for CL 123 will not be created until the type and subtype are defined on the Submission Clinical Study record. If there is a template record with a blank type and subtype and the clinical study token in the Name, a section would be created for both ABC-123 and CL 123.

Limitations

It is recommended you use a Submission join object token for only one join object at a time, as only one such token can be resolved for a Content Plan record at one time. For example, if a Content Plan Template record Name is defined as ${submission_clinical_study__rim} - ${submission_nonclinical_study__rim}, only the ${submission_clinical_study__rim} token is resolved.
Token sections can be nested. For example, a Content Plan Template section using ${submission_language__rim} can be nested under a section using ${submission_country__rim}, which creates a section for each Submission Language under the appropriate Submission Country section.
When multiple tokens from one or more different objects are used in a Content Plan Item or Content Plan Item Template, Vault attempts to populate all tokens if the Submission join reference is populated on the Content Plan Item. If the join reference is blank, the token is not resolved.

Additional Configuration for Tokens

To use a token in a content plan template, you must ensure that the corresponding Submission join fields and matching fields are added on the Content Plan object types. For example, if you add the ${submission_pharmaceutical_form__v} token to a Regional (Module 1) Content Plan Template record, ensure that the Submission Pharmaceutical Form and Pharmaceutical Form fields are added to the Regional (Module 1) Content Plan object type. Otherwise, errors will occur during content plan creation.